Best Practices: Integrating Exchange with an Exchange "smart host"?
( sorry for the double post, I didn't know for sure what group to use ) Here is the situation. I would like to migrate / modernize a small network that is rapidly outgrowing itself. Any pointers to information, white papers or setup guides for a scenario like mine would be welcome. The current situation is as follows... A Exchange 2003 server forms the hub for mail storage for all users. This Exchange is NOTintegrated into emailoutside the intranet in any fashion (no SMTP outbound smarthost, no POP3 connectors etc.). Some clients use Outlook over HTTP to connect remotely or use OWA when traveling. Each user is running Outlook 2007 Each user also has multiple outside POP3 mailboxes that serve as their primary outside communication addresses. So the most common scenario is that Outlook has the Exchange connection set up as the primary. It then has POP3 accounts added, with the delivery settings pointed at the Exchange Inbox. Most of the time, this works just fine. The incoming POP3 mail is processed by Outlook and then deposited into Exchange. In effect the Outlook accounts act as POP3 connectors. Replies to POP3 sourced email go out via SMTPvia the originating accounts and so on. In short, it works but it has a few flaws. Reliance on servers outside our control for the POP3 hosting. If a workstation is shut down or Outlook is closed, that account fails to pull in the POP3 mail and thus is unavailable via OWA. As currently configured OWA cannot be used to reply to any email that sourced from a POP3 account, as there is no smart host configured. Ihave pretty much a free hand to solve this situation... and I was wondering what your best suggestion is. What we do NOT want to do is allow direct internet connection to the intranet Exchange server. Not least of which is the reality that the business DSL line that connects the Intranet to the the Internet is simply not 100 reliable. We need a relay / store buffer. My thinking so far is this... Host an Exchange server on anexternal co-located box. Set it up as the MX target for the external domains we need to receive email at. I can use Exchange 2003 or 2007 for this. Maintain the intranet exchange server essentially as is (we will be transitioning it to Exchange 2007 soon) The Outlook clients should NOT need to connect directly to the external server. They will be able to connect exclusively to the intranet server and receive / send all mail. Then we allow the intranet server to connect to sync with the external server and exchange email. Sending outgoing email and pulling in the incoming email and integrating it with the primary exchange boxes of the users in question. It is critical that in the event the DSL line goes down that the external server buffer and store the email till we re-connect. It is also critical that purely internal information (public folders, internal to internal messaging and so on) not be mirrored or sent to the external exchange server. This is a corporate security requirement. Ideally the external server would allow us to provide OWA accounts to users who had no intranet account and that those be "stand alone". Any help would be greatly appreciated. I am sure this is a problem that has been solved by others. I am sure there is a way for one Exchange server to be a "smart host" front end for another in a loosely coupled way. Thanks!
January 24th, 2008 4:09pm

I've seen setups like this before and it never ceases to amaze me that people use Exchange in this way. The issues you mentioned are just the beginning, you also have inconsistent email flow, depending on who sent what, untraceable mail, and many other features Exchange offers goes to waste. But I digress... You could get a pop connector for exchange to keep a similar setup you have now, but consolidated. Here are some to choose from: http://www.slipstick.com/exs/popconnect.asp What I would do is use a service like postini to have your external MX records point to. They clean your mail for spam and viruses and then pass it along to your server like a normal smtp connection. You can choose to encrypt traffic in both directions with postini, and you can deny inbound tcp25 to everyone except them, essentially keeping Exchange smtp "off the internet". This would then allow you to use rpc over https and have a much simpler, more conducive email architecture. Finally, postini, and people like them (mxlogic) spool your mail. That is, they keep it in their system until your server connection is restored.
Free Windows Admin Tool Kit Click here and download it now
January 25th, 2008 5:11am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics